It is known to use a remote computer terminal to view and control mobile phones using a Virtual Network Computing (VNC) application running both on the remote computer terminal (VNC viewer) and the mobile phone (VNC server). The contents of the display of the mobile device are duplicated on the remote computer terminal. The remote computer terminal has an interface mechanism which allows the user to send user input events, such as pressing a physical key on the device or touching a touch screen input, to the mobile device being controlled. As will be appreciated, the form of data link and the nature of the remote computer terminal can vary, depending on the situation being used.
The remote computer terminal may be for a support engineer using the remote control facility to provide device support to a customer using a mobile phone. If a customer of a company experiences a problem with a mobile phone, such as being unable to send picture messages, the support engineer can diagnose and fix the problem by viewing or interacting with the phone by using the remote terminal. Alternatively, the support engineer may use the remote terminal to install or update software or other settings on a user's mobile phone. In this situation the data link would typically be via a form of radio communication, such as Wifi, GPRS or HSDPA and the remote terminal may be a long distance, e.g. hundreds of miles away from the mobile phone.
Alternatively, the remote terminal may be located close to the mobile phone for example in the automotive industry. The remote terminal may be a headunit embedded as a large display mounted on the dashboard of the car. The familiar interface of the user's phone is shown on the display and the user can use this interface to play music or perform map based navigation. Typically, there will be additional safety mechanisms to prevent the user from using the remote terminal to control distracting applications, such as computer games, while driving. In this situation the data link would typically be via a physically wired connection, such as USB, or a short range radio communication system, such as Wifi or Bluetooth.
Particularly, but not exclusively, in the automotive setting, the mobile device and remote terminal (i.e. headunit) are typically resource-constrained devices, which can have wide-ranging hardware specifications. Furthermore, as well as supporting a VNC session, both the mobile device and headunit may run one or more third party applications, which also compete for the resources of the device. These applications may also utilise the interface between the mobile device and headunit, affecting the bandwidth that is available to support the VNC session.
A VNC session requires the configuration of a number of parameters. Many of these parameters require negotiation between the VNC server and VNC viewer, and some parameters can be mandated by either side. One key factor in the performance of a VNC session is the configuration parameters used by that session. Properties such as pixel format, encoding and encryption can all be varied through configuration parameters. Some of these parameters must take on mandated values for a particular scenario, but others can be tuned to optimise performance.
During a VNC session, a VNC viewer requests that pixel data be provided in a particular format and encoding type. A pixel format defines how a pixel should be described. It specifies the number of bits to use to describe the pixel and how the red, green and blue component information is encoded. The greater the number of bits used to describe a pixel, the more distinct shades of colour that can be communicated through the VNC session. However, increasing the number of bits also increases the amount of data that must be transferred from the VNC server to the VNC viewer to describe a framebuffer update.
An encoding type specifies how pixel data should be sent by the VNC server. An encoding type can facilitate the compression of pixel data, reducing the number of bytes being sent over the wire. For example, pixel data can be encoded using JPEG encoding, a compressed image format. However, whilst compressing pixel data reduces the number of bytes required describing a framebuffer update, this also requires extra CPU resources on both sides of the VNC session to encode and decode the data.
One solution for dynamically adjusting the parameters is shown in FIG. 1 and described in more detail below. In FIG. 1, the pixel format and encoding type are adjusted according to a performance metric, namely Line Speed Estimate (LSE).
The present applicant has recognised that the set of VNC session parameters that allows the best performance to be attained is highly dependent on the properties of the server and viewer platform hardware, the speed of the interface connecting the viewer and server and the influences presented by third party applications. In this light, the present applicant has recognised that an improved method and system for remote controlling mobile phones is required.